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Abstract 

The design and development of a 
Closed-Loop System to study and evaluate the 
performance of the Honeywell Recoverable 
Computer System (RCS) in electromagnetic 
environments (EME) is presented. The 
development of a Windows-based software 
package to handle the time critical 
communication of data and commands between 
the RCS and flight simulation code in real-time, 
while meeting the stringent hard deadlines is 
also presented. The performance results of the 
RCS while exercising flight control laws under 
ideal conditions as well as in the presence of 
electromagnetic fields is also discussed. 

Introduction 

The problem of verifying the integrity of 
control computers in adverse as well as nominal 
operating environments is a key issue in the 
development, validation, certification, and 
operation of critical control systems for 
advanced aircraft. An adverse operating 
environment of particular concern relative to 
validation and certification of critical systems is 
caused by electromagnetic disturbances. 
Sources of electromagnetic disturbances include 
lightning, High Intensity Radiated Fields 
(HIRF) caused by RF transmitters and radars, 
portable electronics devices carried onto the 
airplane, and electromagnetic incompatibilities 
of equipment installed on the aircraft [1], 

Soft faults in digital avionics have 
traditionally been manually corrected. More 
recently, architecture design measures for the 


automatic correction of soft faults have begun to 
be developed. It is perceived that significant 
benefits can be gained through soft fault 
protection measures designed into the basic 
system mechanization. Architecture designs 
with soft fault protection provide the ability to 
tolerate disruption of either input/output data or 
internal computation. Fault clearing and 
computation recovery must be rapid enough to 
be “transparent” relative to functional operation 
and flight deck effect [2]. 

RCS 

An example of an architectural soft fault 
protection philosophy in the design of 
computing platforms is the Aircraft Information 
Management System (AIMS) used on Boeing 
777 aircraft. All computing and I/O 
management resources are lock- step compared 
on a processor cycle-by-cycle basis. In this 
approach, if a soft or hard fault event occurs, the 
processor is interrupted and service handlers 
take control and no data can be exported [2] . 

The first stage of a prototype computing 
platform for fast recovery from soft faults has 
been developed for NASA. This prototype 
includes patented technology for transparent 
soft fault recovery that had never been built or 
tested. These concepts were implemented and 
integrated into the basic lock-step processing 
module of the AIMS architecture. This 
prototype was delivered to NASA in 1997 for 
evaluation at the Fangley Research Center 
(FaRC) system integration facility. A general 
illustration of a computing platform with rapid 
(transparent) recovery elements is depicted in 
Figures 1 and 2. 
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Figure 1. Digital Processor with Elements for 
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Figure 2. Rapid Recovery Upset Detection 
and Recovery Flow 

Such a platform is intended to provide soft fault 
recovery that would be virtually software 
independent and transparent to a system 
function. As shown in Figure 2, the rapid 
recovery concept involves protecting and 
recovering the significant state variables of a 
system function. An aircraft autoland (arm, 
capture and track) function is being used for 
evaluation of the rapid recovery concept. Since 
this is the only function being implemented in 


the application program software, the 
partitioning portion of the platform SAFEbus 
technology was not employed. Communication 
with the LaRC host system integration facility is 
intended to be accomplished primarily through 
an optical 429 bus structure. LaRC has 
identified the platform integrated with the host 
facility as the RCS [2], 

System Architecture 

The proposed Closed-Loop architecture 
consists of the RCS, a VME-based 429-optic 
card for conversion of data from electrical to 
optical and vice versa, a flight simulation host 
processor, and a PC for the development and 
display of data as shown in Ligure 3. 
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Figure 3. Closed-Loop System. 


Two platforms were considered. The first 
alternative is a VME-based system, Figure 4, 
where the flight simulation host is a VME-based 
processor that communicates with the 
development processor, a PC, via a secondary 
link, an RS232 or an Ethernet. 
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Figure 4. VME-Based System. 
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The second alternative bypasses the VME-based 
processor and implies implementation as well as 
operation of the flight simulation on one or two 
PCs, Figure 5. 
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Figure 5. PC-Based Systems. 

PC or VME? 

A VME-based system consists of 
expensive hardware and software compared to a 
PC-based system. Although there are extensive 
and specialized software packages available for 
the VME-based systems, there are steep 
learning curves associated with them. However, 
with in-house knowledge of C/C++ and 
Windows Development software, the PC-based 
system imposed only a minimal learning curve. 
Regardless of the choice of architecture, the 
only new element that needed to be developed 
was a 429-interface package. 

The VME-based systems were expected 
to be able to handle real-time operation of the 
flight simulation. However, real-time display of 
data would still have to be done through a 
secondary network and on a PC. As a result, 
managing the critical timing issues between the 
two computers was not a trivial task. Since 


available PCs are very fast and powerful and 
relatively inexpensive, it seemed practical to 
attempt to perform the flight simulation 
operation, as well as collection and display of 
data on one PC. The challenge, therefore, was 
proving the feasibility of managing the system 
and real-time display of data on a PC. 


Software Development 

A Graphical User Interface (GUI) 
package was developed for Windows 95 using 
C/C++ languages. This modularized and user- 
friendly software consists of 429-interface and 
flight simulation code. It manages 
communication between the RCS and the flight 
simulation code and displays the data in real- 
time while meeting timing requirements of the 
RCS, Figure 6. This software consists of 11 
windows that depict all Closed-Loop System 
activities. Roll and Aileron command 
(DELAC), Pitch and Elevator command 
(DELEC), and Altitude (ALT) and Radio 
Altitude (HR-ALT) are displayed in three 
different windows to provide the user with 
visual correlation between the RCS inputs and 
their corresponding output commands. The 
lateral position (YCG), throttle (THROT), and 
yaw are also displayed separately. In addition 
to an error monitoring window, there are four 
other widows that display the discrete values 
reported by RCS. As a result, this software 
monitors all activities of this Closed-Loop 
System. This real-time monitoring capability is 
essential for testing the system in the presence 
of RF. 

To prevent damaging the RCS, RF and 
field strength are gradually increased until a 
region of susceptibility is visually detected. 
During test runs, the airplane attitude as well as 
RCS status information, i.e., 429 discrete words, 
are displayed in real-time in their corresponding 
windows. Upon upset detection, RF is turned 
off for the remainder of the flight while system 
activities are continuously monitored and data 
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Figure 6. RCS-Win Software. 


collected. Through this user-friendly software, 
test conditions can be specified and recorded 
along with the data for future references. 

Data Management 

The data along with the test conditions 
such as the RCS control flags, field strength 
range, and initial frequency are stored on the 
hard disk. Each file is approximately 1.5 
Mbyte. A 1 Gbyte removable hard drive and a 
CD-ROM writer are used for archival storage. 
The collected data are in ARINC format [3] in 
order to minimize the storage requirements. 
The user interface software is then used to 


convert these data files to the desired format for 
post analysis purposes. 

Tests 

Tests for the RCS are conducted in two 
phases. Phase one consists of testing under 
ideal conditions where EME is absent. Phase 
two consists of testing in the HIRF chambers in 
the presence of EME. The specific goals are to 
characterize the RCS functionality and the RCS 
upset recovery scheme, to verify control laws 
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and flight simulation integrity, and to assess 
RCS performance under various conditions. 

Phase one was necessary in order to 
resolve discrepancies in the Interface Control 
Document (ICD) and to debug the system as a 
whole. Completion of phase one also led to the 
detection of errors in the implementation of the 
flight control codes in the RCS, Figure 7. 





Figure 7. RCS 737 Autoland, no EME. 


As shown in the Pitch and DELEC 
window of Figure 7, there is a spike in the 
DELEC command at the glide slope 
engagement as reported by the RCS. Although 
this discrepancy is not detrimental to the 
operation of this Closed-Loop System, it is 
currently being resolved. 

In Figure 7, Pitch and Elevator 
command, Altitude and Radio Altitude, and Roll 
and Aileron command are displayed in three 
different windows, respectively, to provide 
visual correlation between the RCS inputs and 
their corresponding outputs. The solid lines are 
for RCS inputs and the dotted lines for RCS 
outputs. 

Phase two of the test is currently in 
progress and to date, two tests have been 
completed. 

Description of Experiments 

The radiation environment of the HIRF 
Laboratory is the reverberation chamber. 
Within the chamber are both transmitting and 
receiving antennas as well as any sensors that 
might be needed for a specific test. The 
components of the signal generation and 
measurement instrumentation consist of a 
synthesized sweeper for signal generation, a 
network analyzer, a spectrum analyzer, an 
oscilloscope, and a high-power amplifier [4, 5]. 
These devices are software controlled from 
within the HIRF Laboratory. The advantage of 
performing tests in mode-stirred chambers is 
that the equipment is subjected to fields at all 
angles of incidence simultaneously. Therefore, 
the worst case conditions are represented during 
the test. The reverberation chambers within the 
HIRF Laboratory provide near-homogeneous 
randomized electromagnetic fields and make it 
possible to place the entire target unit in the test 
environment. 

During the test, the RCS is placed inside 
one of the mode-stirred chambers of the HIRF 
Laboratory and is interfaced to the flight 
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simulation computer. Electrical isolation is 
achieved via fiber optic cables. 

While testing the RCS in the HIRF 
chamber, RF and/or field strength are gradually 
increased until a region of susceptibility is 
detected. To prevent damaging the RCS and 
upon upset detection, RF is turned off for the 
remainder of the test. The test is then resumed 
with finer increments of frequencies and/or field 
strength around the susceptibility region. 

Closed-Loop HIRF Data 

The RCS was exposed to RF 
continuously; however the field strength was 
ramped up from minimum to maximum in 10- 
second intervals while keeping the frequency 
constant. The same process was repeated for all 
frequencies. Table 1 is an example of the test 
conditions. 


Table 1. Test Conditions with Continuous 
HIRF Exposure. 


Frequency 

(MHz) 

Min Field 

(V/m) 

Max Field 
(V/m) 

200 

200 

1000 

250 

200 

1000 




2000 

200 

1000 


To date, no repeatable upsets have been 
detected for the frequencies and power levels 
shown in Table 1. Besides Continuous Wave 
(CW), RCS has been exposed to Square Wave 
(SQW) with all modulations per DO- 160 
specification for all of the frequency and field 
strength ranges specified in Table 1. 
Preliminary data from 175 flights indicate that 
the RCS is resilient to the EME. 

Upon disabling the recovery capability 
of the RCS and subjecting the RCS to the same 
set of tests, RCS seemed somewhat more 
vulnerable to RF. Figure 8 shows a second 
spike in the Pitch and DEFEC window that is a 
result of RF induced upset. As evident in the 
Altitude window, this upset caused the airplane 


to crash. Out of 165 flights, two upsets were 
observed, but they were not repeatable. 
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Figure 8. RCS 737 Autoland with 
Continuous HIRF Exposure and RCS 
Recovery Scheme Disabled. 
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Future Test Plans 

Preliminary test results indicate 
resiliency of the RCS to the EME at frequencies 
and power levels used in tests. Since following 
the DO- 160 specification will require 
considerable amount of time in order to find 
susceptible frequencies and power levels, 
another approach will be considered. The next 
test of RCS will be conducted in the Semi- 
Anechoic chamber of the HIRF Laboratory. In 
this chamber emission tests are expected to 
result in detection of some of the susceptibility 
regions of the RCS. The test will continue in 
the reverberation chambers to verify and 
characterize the predicted susceptibility regions. 
In order to fully characterize the performance 
capabilities of the RCS to recover from upsets, 
some of the RF shielding will have to be 
removed to increase the number of upsets that 
occur during the tests. 

Summary 

The design and development of a 
Closed-Loop System to study and evaluate the 
performance of the advanced RCS architecture 
when subjected to EME is presented. The 
integration of this hardware proved to be a 
major undertaking. During this process a few 
bugs in the 737-control law implementation of 
the RCS were found that are being resolved. In 
support of this Closed-Loop System, a 
Windows-based software package was 
developed to handle the time critical 
communication of data and commands between 


the RCS and flight simulation code, in real-time 
while meeting the stringent hard deadlines. 
This package consists of an ARINC429 bus 
driver, flight simulation code and GUI-based 
displays of the key elements of the control laws, 
as well as the airplane attitude. As a result, this 
package enables the researchers to monitor all 
activities of the airplane during the flight in real 
time. The real-time capability of this package is 
crucial during the EME testing of the hardware. 
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